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(57) Abstract: There is disclosed an apparatus and method for limiting mnnel trafQc in a network. TrafBc engineering tunnels are 
used to direct traffic along a predefined path, which may differ from the path that intemet protocol (IP) routing would detennine. 
Interior gateway rotocol (G.GP) cut through will allow the forwarding of all destinations downstream of a tunnel through the mnneU 
without the operator needing to specify a forwarding equivalence class (FEC). But congestion in the tunnel and network instability 
may result from this approach- A solution to these problems is disclosed which limits the Uaffic in the tunnel to only that with 
destination addresses of the dinners egress router or nodes directly supported thereby. Other solutions are disclosed which allow 
tonnel trafBc to nodes having destination addresses other than those being directly supported by the tunnel's egress router. All of 
these solutions are achieved in both pre-deteimined forwarding entry and dynamic packet-by packet embodiments. 
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SYSTEM^ DEVICT^OT> METHOD FOR UMTITNG tMnEL TRAFFIC 
IN AN INFORMATION COMMUNICATION NETWORK 



FIELD OF THE INVENTION 



The present invention relates generally to information communication 
networks and, more particularly, relates to limiting tunnel traffic in such 
10 networks. 



BACKGROUND OF THE INVENTION 

15 

Computer networks are having more and more of an impact on human 
interaction with the passage of time. For one sample, Ihe Internet, which is 
currently used by only about 5% of worldwide human population, is being 
recognized as a boon to mankind. Accordingly, the IhtCTiet, is rapidly 

20 growing in usage on a global basis, is bringing a vast array of useful 

information to those members of our global village who are Internet users, 
and is fostering communication between diverse cultures located aroimd the 
globe by way of the email system. As is widely known, the Internet has its 
foundation in globally-deployed computer networks. For other examples, 

25 one could dte rapidly growing non-Internet local area network (LAN) usages 
of computer networks in industry, academia, government, and elsewhere. 
Accordingly, information (traffic) on aU of these networks is building at an 
accelerating pace which is creating an urgent need for finding additional 
solutions to network traffic congestion and traffic-induced network-instability 

30 problems. 

One such solution involves the use of what is known in the art as 
"tunnels'^ These are computier software/protocol network-constructs which 

„ typically employ "^labels^"^^ as in the multi pr otoc ol label sjrstem (MFI^). For 
example, these labels can override destination addresses in the headers of 

35 network information or data packets received at a router. This router may be 
the input router to a particular tiormel, where the labels allow forwarding such 

-1^ 
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network inf ormatio!^' messages or binary-styled data pac^w from the 
input router via ttie tunnel to its exit located on its tail-end router or network 
device. These tunnels can provide rapid movement of traffic from entrance to 
exit devices, thus reducing the handling of this traffic at every network device 

5 or node therebetween and speeding-up ttie process of communication. In 
other words, traffic engineering tunnels are used to direct traffic along a 
predefined path, which may differ from the path that IP routing (Internet 
Protocol routing) would have ottierwise determined. This one network 
feature, tunneling, can thus be a step in the right direction with regard to 

10 solving or managing the increasing network traffic problem. 

However, tunnels have certain limitations. One of the problems with 
timneling is that it can cause network instability as it is being incorporated 
into a network. For example, consider a tunnel being created between an 
ingress or head-end router and an egress or tail-end router in a network 

15 having a number of other routers, switches, and other network nodes with 
links connecting all devices. Traffic that is upstream of the tunnel's ingress 
router and destined for routers downstream of the tuimel's egress router will 
be directed towards the ingress router to try to get a "quick ride through the 
tunnel". This creates an instability in the network since traffic across the 

20 network, which otherwise would or should have been generally imiformly 
distributed, is being subjected to a perturbation caused by a single tunnel 
being introduced into the network and attracting traffic to its head-end. In 
other words, normally when an MPLS Traffic Engineering (TE) tunnel is 
created, it causes an aggregation of traffic to the tunnel's tail-end router, since 

25 the newly created tunnel appears to be the best path to all destinations 

beyond the tail-end router. In many cases this is not desirable. When initially 
configtiring MPLS TE tunnels, there is a problem with network stability; but, 
once tunnels are configured ever3rvyhere the problem is reduced. An 
approadi to a solution to this instability problem is to try to (1) introduce a 



30 pluraUty of tiiimels in a generally uruf onrdy-distributed inann^ 

the network aiiid (2) introduce &iem all generally at tihe same time. If 
successful, under these circumstances, the above-noted ix\stabilities can be 
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reduced and might be avoided. However, this approach is i^Rvithout 
frustration because it can be a challenging problem to xinifonnly introduce a 
plurality of tunnels into and across a complex network at approximately the 
same time. 

5 Another problem with tunneling and related to the scenario jtist 

described is a traffic congestion problem williin the tunnel itself. This 
problem is created when all or most of traffic upstream of iiie tunnel's head- 
end router that is destined for network devices or other nodes downstream of 
the tunnel's tail-end router wotild like to use the tunnel to get there. Under 

10 these drcumstances, traffic-handling capacity of the tunnel can quickly be 
exceeded and congestion and delay, including loss of information, can lesvlt. 
This problem occurs frequeniiy when using current protocols such as, for 
example, a currently-popular network proiocol known as "Interior Gateway 

Protocol (IGP) cut through". IGP cut through is used within local area 
15 networks (LANs) or within autonomous systems (ASs) [to be contrasted with 
wide area networks (WANs) which connect one or more LANs or ASs via 
gateways]. IGP cut through is described in an IETF (Internet Engineering 
Task Force) draft entitled "Calculating IGP Routes Over Traffic Engineering 
Tunnels", is available on line at "draft-hsmit-mpls-igp-spf-OO.txt", was 
20 autiiored by Me^rs. Henk Smit and Naiming Shen and published in June, 
1999, and is incorporated by reference herein in its entirety. The main 
advantage of IGP cut through is that packets with destination addresses 
downstream of the egress router of a tunnel will automatically use the timnel 
without a himian operator ixeeding to specify those destinations as part of a 
25 forwarding equivalency dass (FEQ. Thus, all destinations downstream of the 
tunnel's exit become part of an implied FEC(IFEC). But, using IGP cut 
through causes the htunan operator to lose his/her. ability to direct traffic 
through ihe timnel which can result in a problem of severe tunnel traffic 

■ con g^tion. _ [ ^ _ . ^ 

30 "liiese problems of network instability and tunnel congestion are 

addressed by the welcome arrival of the present invention which not only 
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offers a solution to these problems but does so while also allowing continued 
usage of the poptilar IGP cut through protocol. 

SUMMARY OP THE INVENTION 

5 

Embodiments of the present invention include methodology, 
apparatus and/or computer program product for limiting traffic volume in a 
ttinnel in an information commimication network. Such traffic volume 

10 limiting initially involves establishing a ttinnel between a head-end router 
and a tail-end router in the network and then determining which network 
devices are directly-connected to the tail-end router. Then such traffic voltune 
limiting involves routing certain information destined for such directly- 
connected network devices from head-end router to tail-end router through 

15 the tunnel. Accordingly, other information not destined for directly-. 

connected network devices is not routed through the timnel thereby limiting 
traffic volume in the tunnel. 

In another aspect of the present invention the tunnel is a traffic 
engineered MPLS tunnel and routing of that certain information includes 

20 affixing a label to that certain information identifying the tail-end router as its 
destination, thereby allowing any transit routers in the tunnd to switch- 
forward that certain information based solely on the destination on the label. 
This reduces the processing load on those transit routers, freeing-up such 
transit routers for other tasks as may be needed and speeding-up transit time 

25 for that certain information through the tunnel. The tail-end router removes 
the label and forwards that certain: information based on destination 
addresses contained in that certain information to hosts and siibnets directly 
connected from and supported by the tail-end router. 

In yet another aspect of the present invention the head-end router 

30 - includes a link-state database allowing such router to deterrnine the network 
devices to which its tail-end router is directiy and indirectly connected. The 
information destined for other than such directly-connected hosts and subnets 
is routed by routes other thaii through the tunnel. 
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Alternative embodiments of ihe present invention in^He limiting 
traffic in the tunnel by defining subsets of traffic received by the head-end 
router and forwarding over or through the tunnel at least one of those 
subsets. In particular implementations, subsets forwarded over the hinnel are 
destined for the tail-end router or for nodes or devices direcdy served (one 
hop in certain protocols) by the tail-end router. 

Further alternative embodiments indude limiting traffic in a 
multipHcity of tunnels extending firom the head-end router by defining a like 
multipHcity of subsets of traffic received by the head-end router and 
forwarding each one of those subsets over a different one of the tunnels. In 
particular implementations, subsets forwarded over the tunnek are destined 
for respective tail-end routers or for nodes or devices directly served (one hop 
in certain protocols) by those tail-end routers. 

In a system aspect of the present invention for controlling traffic in a 
network, determination logic is operatively coupled within the network 
employing an appropriate protocol to determine a first subset of network 
devices which are no more than a selected number of hops (N hops) away 
from the tail-end router. The head-end router forwards over the tunnel a 
second subset of traffic destined for the tail-end router and/ or the first subset 
of network devices or any one or more of these devices. In a further feature, 
control logic measures level or volume of traffic in the tunnel and ac^usts the 
level or volume by changing the number (NO of hops in, and therefore the 
number of network devices in, the first subset. 

In another system aspect of the present invention for limiting traffic in 
an inf omnation communication network, a subset of additional network 
devices directiy supported by or within N-hops from the tail-end router is 
determined. Then by using the Dijkstra algorithm or by other ways the 
shortest path from the head-end router to each node or device in the subset is 
_deteriiiined^.:Thereaftear,_any tunnels connected.j&rpm router to _. 

any of these nodes or devices having a metric less than its corresponding 
shortest path is determined. And, entries in tiie head-end router' s router or 
forwarding table are filled with any tunnel or timnels shorter tiian any of their 
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corresponding shoitff paths, but only with those having tt^Rnimum 
metric. In a further feature, absent any tunnel or tunnels shorter than any of 
their corresponding shortest paths, entries in the table are fiDed with any 
tunnel or tunnels equal to their corresponding shortest paths. In yet a further 
5 feature, absent any of the above-mentioned tunnels, entries in the table are 
filled with neighbor nodes forming route(s) having the minimum metric or 
shortest path. 

It is therefore advantageous and beneficial to employ the present 
invention in computer networks in which tunnels are utilized, to avoid 
10 destabilization and congestion problems associated with those tuimels that 
otherwise do not limit their respective traffic levels or volumes, whereby 
overall speed and efficiency of communication in the network is enhanced. 



15 BRTEF DESCRIPnON OF THE DRA WINGS 

The foregoing and other objects and advantages of the invention vnll 
be appreciated more fully from the foUowing further description thereof with 
20 reference to the accompanying drawings wherein: 

Fig. 1 is a schematic diagram of an information communication 
network illustrating both multiple routes between a tunnel's head-end and 
tail-end routers and a plurality of network devices directly and indirectly 
supported by the tail-end router, and in which embodiments of the present 
25 invention can be used to advantage; 

Fig. 2A is a schematic diagram of information or data packets received 

by ttinnel head-end router AlOl of Fig. 1; 

Fig. 2B is a prior art illustration of a head-end or ingress router's ii\ap 

table or routing table or forwarding entry table in which destiimtion 

^0 addresses ofincoming packets of informatiori and/or data mapped to 

particular outgoing interfaces or ports on such router; 

Fig. 2C is an illustration of a head-end or ingress-router's map table or 
routing table or forwarding entry table filled with table entries in 
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conformance with aifl^odiment of the present invention ^fciich 
destination addresses of certain subsets of traffic or incoming packets of 
information and/or data are mapped to particular outgoing interfaces or 
ports on such router; 

Fig. 3 is a flowchart illustrating the prior art approach to usage of 
tunnels in information communication networks; 

Fig. 4 is a flowchart illustrating an algorithm utilized by an 
embodiment of the present invention; 

Fig. 5 is a flowchart illustrating an algorithm utilized in the process of 
filling the table entries in accordance with another embodiment of the present 
invention; and. 

Fig. 6 is a flowchart iUustrating an algorithm associated with a system 
for controlling level or volume of tunnel traffic in accordance with principles 
of the present invention. 

DFTATLED DESCFTPTION OF A PREFERBFT) EMBODIMENT 

Referring to Fig. 1, there is dqpicted an information communication 
network including multiple routers A, B, C D, E, and F as well as subnets 107 
and 108 connected by various links. More specifically, ingress or head-end 
router AlOl is shown with an input 125 which receives traffic or infonnation 
or generic packet 123 (more detail about these packets is discussed in 
connection with Fig. 2A). Router AlOl may have many output ports but 
shows only two output ports or interfaces 1 and 2 connected by linkllO to 
router B102 and link 109 to router C104 respectively. Link 109 is depicted as a 
tunnel and link 110 is depicted as other than a tunnel and could be a link 
based on OSPF (Open Shortest Path First) or some other protocol. Router 
B102 is connected via link 110 to tail-end or egress router E. Router C104 is 
_OTjmertedviatunri^l09toTO^ . 
tunnel 109 also to tail-end router E103. Thus, there are two pathways shown 
between ingrfess and egress routers in this Hg., one being a tunnel and the 
other not being a tunnel. Fiiwlly, Router E103 indirectly connects to subnet 
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108 through router F106 via links 112 and 113 (two hop coimigm certain 
protocols), but router E103 directly connects to subnet 107 via link 111 (one 
hop count in certain protocols). Each subnet is an autonomous network and 
would typically contain routers, switches, host computers and other network 
5 nodes, each such item having its own address within its autonomous 
network. 

As is understood by those familiar with this art, a tunnel involves 
technology that enables a first network to send its data by way of another 
network's connections, typically by encapsulating a first network's protocol 
10 within packets carried by the second network. For example, one can employ 
MPLS which is an integration of Layer 2 and Layer 3 technologies and uses 
labels which override the destination addresses of the packets. Thus, a hard- 
coded communication pathway is created based on these labels having a 
particular destination and such pathway is called a 'label-switched path 
15 (LSP) tuimel". Any routers internal to such tunnel may be directly accessed 
by other routers in the network to perform routing functioiis indepmdent of 
their otherwise dedicated usage as transit routers within the txmnel- 

Also, as imderstood by those familiar with this art, there are variotis 
protocols tihat have been adopted for exchanging routing information within a 
20 LAN and between multiple LANs within the same AS. These are known as 
interior gateway protocols (IGPs). OSPF and RIP are example IGPs that can 
be used to exchange routing information witiiin an autpnomous system (AS) * 
or LAN such as within subnet 107 or within subnet 108. OSPF establishes 
links diroughout tihe network by having routers broadcast individual link 
25 metric information to aU other routers. This is contrasted with REP that 
establishes links throughout the network by having routers advertise their 
data to only neighboring routers which, in turn, pass on the information only 
to successive neighboring routers. The former dass is called link state routing 
4jrotacols.cmd the latti^.dasjs is called dista^^^ The tunn^ of 



30 Fig. 1 can be constructed as an LSP timiiel and the other links shown can be 
constructed in accordance with an IGP. 
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Kg. 2A shows certain characteristics of a number of packets 114, 117, 

121, and 122. In actuality, each packet, including the packets 114, 117, 121, 

122, and 123 (shown in Hg. 1), includes a destination address field indicating 
the final destination of the packet, a source address field ('TROM") indicating 

5 the source of the packet, and a data payload. Each packet typically passes 
through a number of routers along the way from the source to the destination. 
Specifically, each router determines a "next hop" router for each packet, and 
forwards the packet to the "next hop" router. For convenience. Fig. 2A shows 
a 'TO" field representing the "next hop" router for each packet. It should be 

10 noted that the 'TO" field is not an actual field within the packets. For packets 
114, 117, 121, and 122, the "FROM" field and the 'TAYLOAD" field are left 
blank, since these fields are not germane to comprehension of the described 
embodiments of the present invention. In packet 114, the "TO" field shows 
router AlOl and the destination address field shows "Intemal Subnet 107." 

15 This padcet information is interpreted as follows: the packet came firom some 
unknown upstream network node and was sent to Router AlOl as the "next 
hop" router. Router AlOl forwards or routes the packet toward a particular 
node intemal to subnet 107 for which a specific address is provided in this 
packet's header and depicted herein as "Intemal Subnet 107". The payload 

20 field contains whatever data (binary I's and O's) is intended for that particular 
node destination. Packet 117 contains similar information in its fields, but its 
destination address is different from that of packet 114 - packet 117 is 
destined for a particular node intemal to or within autonomous subnet 108. 
Such particular node's address is intended to be represented by "Intemal 

25 Subnet 108" in this illustration. Packets 121 and 122 differ firom packets 114 
and 117 primarily in their respective destination addresses, where packets 121 
and 122 are destined for tunnel tail-end router E103 and router F106 
respectively, rather than nodes within the subnets 107 and 108. Further 
-detailed.discussion.of . these .pa.ckets will bfi prjsented htt^^elow, _ . 

30 Referring next to both Figs. 2B and 2C, Fig. 2B shows a prior art map 

table for purposes of comparison with Fig. 2C, which reflects a map table in 
conf onnance with principles of the present invention. These tables pictoriaUy 
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represent functional essence of operation of certain computei^&dware, 
firmware and/or software in router AlOl of Fig. 1 and are thxis tables of 
binary ntimbers or binary values. However, such values are not shown but 
are represented by their functioiwl equivalents in English language and 

5 dedmal numbers to enhance comprehension of the various embodiments of 
ti\e present invention. A table rqjresaitation similar to these, but with 
different information, can be associated with each router of the network of 
Fig. 1. These tables show columns entitled 'Tacket number" arid 
"Forwarding Eiitry". Packet nimiber is not necessarily an item maintained in 

10 these mapping or router tables, and is shown here as a convenient identifier 
for discussion purposes. On the other hand. Forwarding Entry including its 
sub-colxmms entitled "Destination Address" PA), "Outgoing Interface" and 
"Label Added?" are included in the router tables for substantive operational 
purposes. "The first column and first row or tuple entry in the tables is 

15 packet 114 and is similar to the generic packet 123 depicted in Fig. 1. 
Corresponding to packet 114 is a destination address binary value 
corresponding to a particular node within subnet 107, an outgoing interface 
binary value corresponding to interface or port #2 of router AlOl, and a 
binary value corresponding to answer "yes" to the question of whetiier or not 

20 a label is added to this packet. Similar binary values are associated with the 
table entries for the other packets shown. 

Witfi specific regard to prior art Fig. 2B, packets 114 through 122 are 
shown having destination addresses of either subnet 107, subnet 108, router 
E103 or router F106. (As noted earlier, a designation of "subnet 107" for 

25 destination address means a particular node within subnet 107 and is 

illiistrated in this manner for purposes of convenience, since the internals of 
subnet 107 are not shown in order to enhance clarity of presentation. Thus 

the repetitive destination address designation of "sxibnet 107" also for packet 
Jraambears 115^116, and^^^ ]. 



30 nodes from r the particular node within subnet 107 to which packet 114 is. 

destined.) As can be seen, in Fig. 2A, all packets exit router AlOl via outgoing 
interface or port #2 and all have a label added. All of these packets are said to 
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belong to the same Awarding equivalence dass (FEC), sin^Wey all exit the 
router by way of the same port with the same label. In typical router 
construction, there are multiple printed circuit boards or "cards" associated 
■with tiie multiplicity of outgoing intarfaces or ports in the router, and a card 

5 may have more than one port associated with it. Further discussion of router 
construction detail at this level, however, is not essential to full 
comprehension of the presented embodiments of the present invention. 

Next, with specific regard to Fig. 2C, a map table in accordance with 
principles reflected in embodiments of the present invention is shown. A 

10 principal difference between this table and the one of Fig. 2B is the indication 
that nodes having destination addresses within subnet 108, such as tfiose 
associated with packets 117, 119, and 120, all do iwt have labels added, and all 
are routed out outgoing interfece #1 instead of interface #2. Thus, rather than 
have all inconcdng packets that are destined for addresses downstream of 

15 router E103 go out interface #2 (to the tunnel entrance), now, in accordance 
wilii principles of the present invention, only certain incoming packets (a 
subset of the incoming packets) that are destined for addresses downstream 
of router E103 go out interface #2. 

In operation, referring to Figs. 1, 2A, 2B, and 2C coUectively, traffic or 

20 packets, such as packet 114, are serially received by head-end router AlOl at 
input 125. Packet 114 would ordinarily contain header information which 
would show (in the "FROM" field of the header) where it came from (either a 
local device witiiin this particialar LAN or AS or from a different or remote 
LAN or AS via a network "gatewa/0- The header also shows where the 

25 packet is heading to (in the "DESTINATION ADDRESS" field of the header), 
which, in this case, is a node within internal subnet 107. Upon receipt of this 
packet, router AlOl examines the packet's destination address, and compares 
the packet's destination address against destination address entries in the 

teb^ of Fig . 2C. (For purposes of enhancin g da rity of presentation, a liirated 

30 nimiber of only nine entries are presented in the tables of Fig.2B and Fig. 2C, 
those entries aU being rdated to tail-end routers and downstream routers 
E103 and F106 respectively, and depicted subnets 107/108. It should be 
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understood, however, that the network can be much larger traK that shown, 
with a vast number of subnets and/or network devices and host computers, 
and with a corresponding vast number of destination addresses). A match is 
foimd between the arriving packet's destination address and a destination 
5 address entry in the table, i:e. a node within subnet 107. Thus, the first row or 
tuple of tiie table of Fig. 2C represents a matched association between the 
binary-ntimbered destination address contained in packet 114 entered in the 
first column, and the binary niunbered address of a particular node within 
subnet 107 stored in ihe first row, second colunm headed '^Destination 

10 Address/' The hardware, firmware, and/ or software of router AlOl 
represented by ttiis table thus responds by affixing the computer binary 
equivalent of a label to this particular packet and forwarding it to outgoing 
interface "T as reflected in ttie first row or tuple of the table. Outgoing 
interface or port 2 is the entrance to tunnel 109 by which packet 114 travels to 

15 router C104. Router C104 receives the packet and does not examine its 

destination address like router AlOl did, but relatively quickly (as compared 
with the prior address examination procedure) notes its label and forwards it 
along the timnel based on ihe label information. Router D105 receives the 
labeled packet and performs the same procedure as router C104 and quickly 

20 forwards it to tail-end router E103- Router E103 removes the label and 
forwards the packet to a particular node within subnet 107 over link 111 
based on its original destirmtion address. Other packets similarly destined, 
namely packets 115, 116 and 118, are handled in an identical fashion, and 
their entries in Fig. 2C also represent matched associations between each of 

25 their destination addresses in their respective headers and a matching binary 
number address of a particular node internal to subnet 107 stored in the Fig. 
2C table of router AlOl (which may or may not be the same address to which 
thedestiriationof packet 114 was matched). Thus, packets destined for 
va rious nodes inte^^ to subnet 107 bem . . 

30 egressrouterElOS aresentby way of tiae tunnel. 

In contrast, consider the operation of this network upon a different 
packet, packet 117, which has a different destination address. In Figs. 1, 2A 
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and 2C, generic paclSL23 can also represent packet 117 bei^eceived by 
router AlOl, but in tius case showing a different destination address of 
"Internal Subnet 108" in its destination address field. Thus router AlOl, as 
with aforementioned packets 114, 115, 116, and 118, again proceeds with the 

5 relatively lengthy procedure of examining this new packef s destination 
address and comparing it against destination address entries in its table. As 
before, a match is foimd between the destination address of packet 117 and, in 
this case, a particular node within subnet 108, as reflected in the fourth row or 
tuple of the table in Fig. 2C, counting from the top davm. Thus, this fourth 

10 tuple represents a matched association between the destination address 

(binary numbered) contained in packet 117 shown in the first column and the 
address (binary number) of such particular node within subnet 108 stored in 
the table of router AlOl shown in the second column headed "Destination 
Address." Hardware, firmware, and/or software represented by the table 

15 responds, in this case, by not affixing the computer binary equivalent of a 
label to this particular packet, but by merely forwarding it to a different 
outgoing interface, port "1" based on its destination address as shown in this 
fourth tuple. Outgoing interface or port 1 is the entrance to link 110 by which 
packet 117 travels to router B102. Router B102 receives the packet and in this 

20 case (without a label) must reexamine the packet's destination address like 
router AlOl did. Thereafter, router BlOl forwards the packet along to router 
E103 based on the destination address. Router E103 again reexamines the 
address and forwards the packet to router F106 over link 112. Router F106 
examines the packet's destination address and forwards the packet over link 

25 113 to some node having such destination address internal to subnet 108. 

Packets 119 and 120 are handled in like fashion since they are also destined to 
internal sxibnet 108. Thus, packets destined for nodes, routers, hosts, etc. 
within subnet 108, which is indirectly coimected from tunnel egress router E, 
„ _„_^.e SiSitJjyJKaxtespthjer numbers 121 and 122 

30 reflect packets destined for routers upstream from the subnets; one of these 
routers is the tail-end router and ttie other is directiy supported thereby, 
whereby packets so destined are labeled and proceed via the tunnel. 
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If the tables of Figs. 2B and 2C did not have label columns they could 
have been called generic routing tables. The added label column converts 
each table to what is known as a traffic engineered (TE) tunnel table, since 
addition of labels contribute to creation of titie tunnel. Another way of 

5 describing implementation of tiiis embodiment of the present invention is that 
each router maintains a table of traffic-engineered tunnels that originate on 
that router. After shortest path first (SPF) calculations have been completed 
by each router and routes submitted to its routing table, interior gateway 
protocol (IGP) examines the TE tunnel table and finds all the tail-end routers 

10 for tunnels originating on this calculating router. This is done for each router. 
For each tail-end router f oimd, the link state database is examined to find all 
siibnets directly attached to that tail-end router. For each of these directly 
attached subriets, a route is submitted to its head-end router's TE tunnel table 
witti the tunnel as "next hop". The labels that are ultimately affixed to those 

15 incoming packets which are properly destined take tinis next hop information 
into accoxmt. 

For further explanation with regard to implementation of the table of 
Fig 2C, reflecting an exemplary embodiment of the present invention, refer to 
Fig. 5 which is a flowchart illustrating metrics involved. Metrics can be 

20 viewed as effective "distances" or 'loads" between nodes, such effective 
distances taking into account other factors such as traffic congestion, 
transmission speed of the physical media (e.g. copper vs glass fiber), etc. All 
of this information is available to each of the routers in the network which can 
broadcast such information to all other routers in the network under certain 

25 protocols. In block 501, head-end rOuter AlOl of Fig. 1 determines the 

shortest path to subnet 107 iising the "Dijkstra" algorithm (see almost any text 
on computer networks, such as "Computer Networks" by Andrew S. 
Tanenbaum ptiblished by Prentice Hall). The algorithmic process then moves 
iO-decMon blodc 502 which de termines if any tunnels exist that directly serve 

30 subnet 107 (i.e. that have their respective tail-ends on separate routers such as 
E103 that directly serve subnet 107) that provide metrics from router AlOl to 
the siibnet that are less than the shortest path deterinined in block 501. If 
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"yes", the algorithmic process moves to block 503 reflecting that all such 
tumel(s) having the minimum metric are the forwarding entries that fill the 
table of Fig. 2C. Thus other existing tunnels, if any, directly serving subnet 
107 but having metrics greater than the minimum tunnel metric determined 

5 are not entered into the table. On the other hand, if the answer to decision 
block 502 was "no", where no tunnels in that category exist, then the process 
moves to a second decision block 504 where the same question is posed with 
regard to directly serving subnet 107 but only for tunnels having metrics that 
are equd to the shortest path determined. If the answer to this second 

10 question is "yes", then in block 505 the table in Fig. 2C is filled with 

forwarding entries to subnet 107 conqirising tunnel(s) and neighbor nodes (if 
any) forming route(s) having the minimum metric (in this case equal to the 
Dijkstra-determined shortest path metric). Finally, if the answer to this 
second question is "no", then in block 506 the routing or mapping table of Rg. 

15 2C is filled with forwarding entries to subnet 107 comprised of only neighbor 
nodes (non-turmel nodes) forming route(s) having the minimum Dijkstra- 
determined metric (By contrast, the prior art approach would be reflected in 
decision blocks that are similar as far as the metrics comparison is concerned, 
but are quite different in that they would ignore the "directly-serve" concept. 

20 Thus, the prior art decision blocks would form routes including tunnels that 
would accept traffic destined for all nodes downstream from the tail-end 
router.) It is understood that, in itas embodiment of the present invention, 
this process of filling a routing table of a particular head-end router with 
forwarding entries is one that is performed in advance of any packets arriving 

25 at the input to such router. In other words, in this embodiment of the present 
invention, this is a static, pre-determined process, established in advance of 

packet-arrival to handle packets arriving thereafter. 

As an alternative embodiment of tiie present invention, consider a 

-dynamic approach to-implementation of the present invention. But first, refer.. 

30 to the flowchart of Fig. 3; while reflecting a dynamic approach this Fig. 3 does 
not reflect ^nbodiments of the present invention. The algorithm starts with a 
tunnel being established in block 301. The algorithmic process inoves to block 
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302 where a packetmtti a header is received by the ingressl^ter. The 
algorithmic process moves to decision block 303, which d3mamically 
determines if the packet's destination address corresponds to that of the 
tunnel's egress router or any node downstream from such egress router. If the 
5 answer is "yes'', then the algorithmic process goes to block 304 where the 
ingress router directs such packet(s) to its output port, which is linked to the 
tunnel's entrance. From there the algorithmic process moves to block 306 
where the packet(s) is received at the destination via the ttmnel. Thus all 
traffic to the egress router and downstream therefrom is jammed into the 

10 tunnel. On the other hand, if the answer is "no", then the process moves 
from decision block 303 to block 305 where the ingress router directs the 
packet to another output port having the destination address of the packet(s). 
From there the process moves to block 307 where the packet is received at the 
destination, but not via the ttmnel. 

15 By contrast, consider the algorithmic process of ihe flowchart of Fig. 4, 

which does reflect a djmamically-responsive embodiment of the present 
invention. A tunnel is established in block 401 between ingress and egress 
routers. A packet with header is received by the ingress router in block 402- 
The algorithmic process moves to decision block 403, which dynamically 

20 determines if the header reflects a destination address corresponding to the 
egress router or cfsubnet(s) or host(s) directly supported by the egress router, tb^ 
limiting the traffic through the tunnel to this subset of downstream addresses. 
If the answer is "yes" then the algorithmic process moves to block 404 where 
the ingress router directs such packet(s) to its output port that is connected to 

25 the tunnel entrance. The process moves from there to block 406 where tJae 
packet(s) is received at the destination via the tunnel. On the other hand, if 
the answer: is "no", then the algorithmic process moves from block 403 to 
block 405 where the ingress router directs the packet(s) to another output port 

_ (n ot connected t o the tun nel) and having the destination aiddress of the 

30 packet(s). From block 405 the process moves to block 407 where the packet is 
received at its destination (not via the tunnel). In this case traffic through th^ 
tunnel is limited providing the operational netvvork benefits earlier descril^fid. 
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As noted, ttiis approlm dynamically solves the problem on ^Pcket-by- 
packet basis, where decision block 403 is a dynamic operation in real time, as 
compared with the earlier-described embodiment of pre-determining all 
addresses of all downstream nodes and entering that information in a table in 

5 advance of packet-arrival. 

For another alternative embodiment in the category of dynamic control 
of tunnel traffic in a network, consider Fig. 6. In block 601, within a network, 
establish a head-end router (e.g. AlOl in Fig. 1) connecting to a tail-end router 
(e.g. E103 in Fig. 1) by way of both a tunnel and multiple non-tunnel routes; 

10 there are additional network devices connected to the tail-end router. The 
algoritihmic process moves to block 602 where a particular portion of the 
network traffic (portion of the packets routed and transmitted throughout the 
network) is forwarded to and received by the head-end router. The 
algorithmic process moves next to decision blodk 603 wherein a determination 

15 is made: is such particular portion of received network traffic destined for the 
tail-end router or for nodes no more than N hops (N is an integer greater than 
or equal to a value of one) away from tiie tail-end router? If the answer is 
"yes", tiien in block 604 such particular traffic portion is conducted to a 
particular output port on the head-end router so that it is routed over or 

20 through ttie tunnd. Then, the algorithmic process moves to decision block 
605 wherein it is determined if the level of traffic in the tunnel is acceptable, 
i.e., is the traffic too light where more traffic could be easily handled, or, on 
the ottier hand, is there congestion or instability or other adverse condition 
detected in the timnd? If the answer is "no", that the traffic level is not 

25 acceptable, then the process moves to control block 606, which either 

increases or decreases the number "N" to adjust the subset of downstream 
network nodes ttiat are included in the group having addresses to which 
tunnel traffic will be forwarded. This group of addresses is thus either 
increased or decreased by adjusting the number N upwards or downward^ 



30 respectively, with a lower limit to its value being N = 1 and by feeding-back 
its adjusted value into decdsicm block 603 where the operation of block 603 is 
repeated, but now with respect to this adjusted value of N. Qn other words. 
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this is a dynamic feeSack operation where the sxibset of adc^^es of nodes 
located downstream from the tail-end router of a tunnel to which tunnel 
traffic is being routed or forwarded is adjusted up or down to maintain an 
optimiun level of traffic within the tunnel.) Assuming that this adjusted value 
5 of N results in anottier "yes'' answer from block 603, then tiie concomitant 
adjusted traffic level is routed over the tunnel in block 604. On this iteration, 
if level of traffic in the tunnel is now acceptable (contrasted with the prior 
"no" answer) according to block 605, Hie algorithmic process moves via its 
"yes" output and stops. 

10 On the other hand, returning to decision block 603, if the traffic portion 

received by the head-end router was not destined for the tail-end router or 
was not within N hops of the tail-end router, then the algorithmic process 
moves to block 607 wherein such traffic portion is conducted to head-end 
router output ports connected to mtiltiple routes excluding the ttmnd, and 

15 again the algorithmic process stops. In this manner traffic in the tunnel is 

clearly controlled under two conditions: (1) As noted in embodiments earlier, 
described, if traffic is destined for downstream nodes that are outside of the 
subset of nodes established for servicing by the timnel (e.g. not within the 
class of nodes that are directly supported by the tuimel's egress router 

20 representing under certain protocols a "one-hop" condition or a value of N = 
1) then such destined traffic is conducted to head-end router output ports that 
route such traffic outside the timnel; and (2) If tiie first condition is met, 
where the traffic is destined for downstream nodes that are inside such subset, 
then such traffic in the tunnel is dynamically adjusted to maintain an 

25 optimum traffic level or volume for that timnel, optimimi being determined 
within the context of traffic distribution throughout the entire network. 

It should be noted that the term "router" is used herein to describe a 
communication device that may be used in a communication system, and 
__„_^hQuld not bejzonstni^ tP ilM fee presmt in^ 



30 communication device type. Thus, a conunimication device may indude, 
without limitation/a bridge, router, bridge-router (brouter), switch, node, or 
other commimication device. 
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It should also be noted that the term "packet" is 1^ 
a communication message that may be used by a communication device {e.g., 
created, transmitted, received, stored, or processed by the communication 
device) or conveyed by a communication medium, and should not be 
5 construed to limit the presmt invention to any particular commum 

message type, commimication message fonnat, or communication protocol. 
Thus, a communication message may include, without limitation, a frame, 
packet, datagram, loser datagram, cell, or other type of commimication 
message, 

10 It should also be noted that the logic flow diagrams are used herein to 

demonstrate various aspects of the invention, and should not be construed to 
limit the present invention to any particular logic flow or logic 
implementation. The described logic may be partitioned into different logic 
blocks (e.g., programs, modules, functions, or subroutines) without changing 

15 the overall results or otherwise departing from the true scope of the 

invention. Often times, logic elements may be added, modified, omitted, 
performed in a different order, or implemented using different logic 
constructs (e.g., logic gates, looping primitives, conditional logic, and other 
logic constructs) without changing the overall results or otherwise departing 

20 from the true scope of the invention. 

The present invention may be embodied in many different forms, 
including, but in no way limited to, computer program logic for use with a 
processor {e.g., a microprocessor, microcontroller, digital signal processor, or 
general purpose computer), programmable logic for use v^ih a 

25 programmable logic device (e.g., a Field Programmable Gate Array (FPGA) or 
other PLD), discrete components, integrated circuitry {e.g., an Application 
Specific Integrated Circuit (ASIC)), or any other means including any 
corhbination thereof. In a typical embodiment of the present invention:, 
pxedoininan%^aU of Jhe..he^^^ device logic is im plemen ted as a set of 

30 . computer program instructions that is converted iitto a computer executable 
form, stored as such in a computer readable medium, and executed by a 
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microprocessor wi^Si the head-end device tinder the conn^rof an operating 
system. 

Computer program logic implementing all or part of the functionality 
previously described herein may be embodied in various forms, including, 
5 but in no way limited to, a source code form, a computer executable form, and 
various intermediate forms {e.g., forms generated by an assembler, compiler, 
linker, or locator). Source code may include a series of computer program 
instructions implemented in any of various programming languages (e.g., an 
object code, an assembly language, or a high-level language such as Fortran, 

10 C, C++, JAVA, or HTML) for use with various operating systems or operating 
enviroxunents. The source code may define and use various data structures 
and communication messages. The source code may be in a computer 
executable form {e.g., via an interpreter), or the source code may be converted 
{e.g., via a translator, assembler, or compiler) into a computer executable form. 

15 The computer program may be fixed in any form {e.g., source code 

form, computer executable form, or an intermediate form) either permanently 
or transitorily in a tangible storage mediimi, such as a semiconductor memory 
device {e.g., a RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a 
magnetic memory device (e.g., a diskette or fixed disk), an optical memory 

20 device {e.g., a CD-ROM), or other memory device. The computer program 
may be fixed in any form in a signal tihat is transmittable to a computer using 
any of various communication technologies, including, but in no way limited 
to, analog technologies, digital technologies, optical technologies, wireless 
technologies, networking technologies, and internetworking technologies. 

25 The computer program may be distributed in any form as a removable 
storage medium with accompan)dng printed or electronic documentation 
{e.g., shrink wrapped software), preloaded with a computer system (e.g., on 
system ROM or fixed disk), or distributed firom a server or electronic bulletin 

^-board.over -the-commimication sjfstem (€.g.^JflieIntemet.Qr-WorM W.eb). 

30 Hardware logic (including programmable logic for use witti a 

programmable logic device) implementing all or part of the functionality 
previously described herein may be designed using traditional manual 
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methods, or may beSagned, captured, simulated, or docu^Pted 

eleclronicaUy using various tools, such as Computer Aided Design (CAD), a 
hardware description language (e.g., VHDL or AHDL), or a PLD 
programming language (e.g., PALASM, ABEL, or CUPL). 

5 Programmable logic may be fixed either permanently or transitorily in 

a tangible storage medium, such as a semiconductor memory device (e.g., a 
RAM, ROM, PROM, EEPROM, or Flash-Programmable RAM), a magnetic 
memory device {e.g., a diskette or fixed disk), an optical memory device (e.g., 
a CD-ROM), or other memory device. The programmable logic maybe fixed 

10 in a signal that is transmittable to a computer using any of various 

communication technologies, including, but in no way limited to, analog 
technologies, digital technologies, optical technologies, wireless technologies, 
networking technologies, and internetworking technologies. The 
programmable logic may be distributed as a removable storage medium with 

15 accompanying printed or elecbronic documentation (e.g., shrink wrapped 
software), preloaded with a computer system (e.g., on system ROM or fixed 
disk), or distributed from a server or electronic bulletin board over the 
commtmication system (e.g., the Intemet or World Wide Web). 

Although various exemplary embodiments of the invention have been 

20 disclosed and described, it should be apparent to those skilled in the art that 
various changes and modifications can be made that will achieve some of the 
advantages of the invention without departing from the true scope of the 
invention. The present embodiments are thus to be considered as illustrative 
and not restrictive. These and other such modifications are intended to be 

25 covered by the appended daims. 
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1. In an information communication network comprising a head-end 
device in commimication with a tail-end device via a number of routes for 

5 routing information to various destinations, a method for limiting traffic 
volume in a tunnel by said head-end device, ihe method comprising: 

establishing said ttinnel to said tail-end device as one of said number of 
routes; 

determining a number of said destinatior\s that are serviced by said 
10 tail-end device to obtain serviced destinations; and 

routing information destined for said serviced destinations to said tail- 
end device through said timnel. 

2. The method of daim 1, wherein said serviced destinations comprise 
15 directly-coimected hosts/subnets of said tail-end device. 

3. The method of daim 1, wherein said serviced destinations comprise 
destinations within a predetermined number of router hops of said tail-end 
device. 

20 

4. Themethod of daim 3, further comprising monitoring tunnel 
utilization, wherein said determining further comprises djmamically 
increasing said predetermined number of router hops if said tunnel is imder- 
utilized and decreasing said predetermined number of router hops if said 

25 tunnel is over-utilized. 

5. Themethodof daim 1, wherein said serviced destinations comprise 
said tail-end device. 

30 6. Themethodof daim 1, wherein said serviced destinations comprise a 
destination for which said tunnel is a better route to said destination than a 
predetermined shortest path route to said destination. 
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10 



15 



7. The method of daim 6, wherein said deteraiirung comprises: 
calctilating said shortest path route to said destination; 
determining a shortest path route metric associate witti said shortest 

path route; 

determining a tunnel metric associated with said tunnel; and 
determining from said shortest path route metric and said tunnel 

metric that said tunnel is a better route to said destination than said shortest 

path route. 

8. The method of claim 1, wherein said head-end device comprises a Unk 
state database, and wherein said determining comprises exarnining said link 
state database to determine which of said destinations are serviced by said 
tail-end device. 



9. The method of daim 1, wherein said tunnel comprises a labd switched 
path from said head-end device to said tail-end device, and wherein said 
routing comprises affixing to said information a predetermined labd 
assodated with said labd switched path for label switching of said 

20 information from said head-end device to said tail-end device by a number of 
intermediate devices. 

10. The method of daim 1, wherein said head-end device comprises a 
forwarding table indicating one of said niunber of routes for eadi of said 

25 nurriber of destinations, and wherein said determining further comprises 
indicating said tunnd for each of said serviced destinations in said 
forwarding table. 

11. The metiiod of daim 10, wherein said routing comprises determining 



30 frorn said forwarding table that said information is assodated with said 
tunnd. 
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12. The method ofaaim 1, furttier comprising routing inKmation 
destined for other than said serviced destinations over one pf said number of 
routes other than said tunnel. 
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13. An apparatus^wlkniting traffic volume in a tuimelb^Peen said 
apparatus and a tail-end device, said apparatus having a number of routes to 
said tail-end for routing information to various destinations, the apparatus 
comprising: 

5 tuimel establishment logic operably coupled to establish said tunnel to 

said tail-end device as one of said number of routes; 

determination logic operably coupled to determine a number of said 
destinations that are serviced by said tail-end device to obtain serviced 
destinations; and 

10 routing logic operably coupled to route information destined for said 

serviced destinations from said head-end device to said tail-end device 
through said tunnel. 

14. The apparatus of daim 13, wherein said serviced destinations comprise 
15 directly-connected hosts/subnets of said tailrend device. 

15. The apparatus of claim 13, wherein said serviced destinations comprise 
destinations within a predetermined nvimber of router hops of said tail-end 
device. 



20 



16. The apparatus of daim 15, further comprising monitoring logic 
operably coupled to monitor tunnel utilization, wherein said determination 
logic is operably coupled to dynamically increase said predetermined number 
of router hops if said tunnel is under-utilized and decrease said 

25 predetermined ntuiiber of router hops if said timnel is over-utilized. 

17. The apparatus of daim 13, wherein said serviced destinations comprise 
sjdd tail-aid device. 



30 18. The apparatus of daim 13, wherein said serviced destinations comprise 
a destination for which said tunnel is a better route to said destination than a 
predetermined shortest path route to said destination. 
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19. The apparatus of daim 18, wherein said determination logic is 
operably coupled to calctilate said shortest path route to said destination, 
determine a ^ortest patii route metric associate with said shortest path route, 

5 det^mine a tunnel metric associated wiih said tunnel, and determine from 
said shortest path route metric and said tunnel metric that said tunnel is a 
better route to said destination than said shortest path route. 

20. The apparatus of daim 13, further comprising a link state database, 
10 wherein said determination logic is operably coupled to examine said link 

state database to determine which of said destinations are serviced by said 
tail-end device. 

21 . The apparatus of daim 13, wherein said tunnel comprises a label 
15 switched path to said tail-end device, and wherein said routing logic is 

operably coupled to affix to said information a predetermined label associated 
with said labd switched path for labd switching of said information from 
said head-end device to said tail-end device by a number of intermediate 
devices. 



22. The apparatus of daim 13, further comprising a forwarding table 
indicating one of said number of routes for each of said number of 
destinations, wherein said determination logic is operably coupled to indicate 
said txmnel for each of said serviced destiiwtions in said forwarding table. 

23. The apparatus of daim 22, wherein said routing logic is operably 
coupled to determine from said forwarding table that said information is 
assodated with said turmel. 



30 24. The apparatus of daim 13, wherein said routing logic is operably 
coupled to route information destined for other than said serviced 
destinations over one of said nxunber of routes other than said tunnel. 
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25. A computer pS^am for cohtroUing a head-end devi^R limit traffic 
volume in a tuimd between said head-end device and a tail-end device, said 
head-end device having a number of routes to said tail-end for routing 
information to various destinations, the computer program comprising: 

5 tunnel establishment logic programmed to establish said tunnel to said 

tail-end device as one of said ntmiber of routes; 

determination logic programmed to determine a number of said 
destinations that are serviced by said tail-end device to obtain serviced 
destinations; and 

10 routing logic programmed to route information destined for said' 

serviced destinations from said head-end device to said tail-end device 
through said timnel. 

26. The computer program of daim 25, wherein said serviced destinations 
15 comprise directly-connected hosts/subnets of said tail-end device. 

27. The computer program of daim 25, wherein said serviced destinations 
comprise destinations within a predetermined number of router hops of said 
tail-end device. 

20 

28. The computer program of daim 27, further comprising monitoring 
logic programmed to monitor tunnel utilization, wherein said determination 
logic is further progranimed to dynamically increase said predetermined . 
nuiriber of xouter hops if said tunnd is tmder-utilized and decrease said 

25 predetermined number of router hops if said tunnel is over-utilized. 

29. The computer program of claim 25, wherein said serviced destinations 
comprise said tail-end device. 



30 30. The computer program of daim 25, wherein said serviced destinations 
comprise a destination for which said tunnel is a better route to said 
destination than a predetermined shortest path route to said destination. 
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31. The computer program of claim 30, wherein said determianation logic is 
programmed to calculate said shortest path route to said destination, 
determine a shortest path route metric associate with said shortest path route, 

5 determine a tunnel metric associated with said tunnel, and determine from 
said shortest path route metric and said tunnel metric that said tttnnel is a 
better route to said destination than said shortest path route. 

32. The computer program of daim 25, wherein said determination logic is 
10 programmed to examine a link state database to determine which of said 

destinations are serviced by said tail-end device. 

33. The computer program of daim 25, wherein said tunnel comprises a 
label switched path from said head-end device to said tail-end device, and 

15 wherein said routing logic is programmed to affibc to said information a 
predetermined label assodated with said label switdied path for label 
switching of said information from said head-end device to said tail-end 
device by a ntunber of intermediate devices. 

20 34. The computer program of daim 25, wherein said head-end device 

comprises a forwarding table indicating one of said number of routes for each 
of said niunber of destiriations, and wherein said determination logic is 
programmed to indicate said timnel for eadi of said serviced destinations in 
said forwarding table. 

25 

35. The computer program of daim 34, wherein said routing logic is 
programmed to determine from said forwarding table tiiat said information is 
assodated with said tunnel. 

30 36. Thecomputerprogramof daim 25, wherein said routing logic is 
programmed to route informatiorL destined for other than said serviced 
destiiiations over one of said number of routes other than said timnel. 
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37. The computer program of claim 25 embodied in a computer readable 
medium. 

5 38." The computer program of daim 25 embodied as a data signal. 
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39. In an infonnaKn coirantmication network comprisin^a head-end 
device in communication with a tail-end device via a number of routes for 
routing information to various destinations, a method for limiting traffic 
volume in a tuimel, the method comprising: 

5 establishing said tunnel between said head-end device and said tail- 

end device as one of said ntunber of routes 

receiving information for a destination by said head-end device; 

determining whether said destination is serviced by said tail-end 
device; and 

10 routing said information by said head-end device to said tail-end 

device over said tvmnel, if and oidy if said destination is serviced by said tail- 
end device- 

40. The method of claim 39, wherein determining whether said destination 
15 is serviced by said tail-end device comprises determining whether said 

destination is a directly-connected host/subnet of said tail-end device. 

41. The method of daim 39, wherein determining whether said destination 
is serviced by said tail-end device comprises determining whether said 

20 destination is within a predetermined number of router hops of said tail-end 
device. 

42. The method of daim 41, further comprising monitoring tunnel 
utilization, wherein said determining further comprises d)mamically 

25 increasing said predetermined nimiber of router hops if said tunnel is under- 
utilized and decreasing said predetermined ntimber of router hops if said 
ttinnel is over-utilized. 

The ixiethod of daim 39, wherein determining whether said destination 
30 is serviced by said tail-end device comprises determining whether, said 
destination is said tail-end device. 
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44. The mettiod^ftim 39, wherein deterauiungwheAJMad destination 

is serviced by said tail-end device comprises: 

calculating a shortest path route to said destinations- 
determining a shortest path route metric associate with said shortest. 

path route; 

determining a tunnel metric associated with said tunnel; and 
determining from said shortest pati\ route metric aiui said tunnel 

metric that said tixnnel is a better route to said destination than said shortest 

path route. 

45. The inethod of daim 39, wherein said head-end device comprises a link 
state database, and wherein said detennining comprises examining said link 
state database to determine whether said destination is serviced by said tail- 
end device. 



46. The method of daim 39, wherein said tvmnel comprises a lafeel 
switched path from said head-end device to said tail-end device, and wherein 
said routing comprises affixing to said information a predetermined label 
assodated with said label switched path for label switching of said 

20 infbrxnation from said head-end device to said tail-end device by a number of 
intermediate devices. 

47. The method of daim 46, wherein said routing further comprises said 
tail-end device removing said label from said information and forwarding 

25 said inf orrnation to said destinations based upon destination adtkess 
information in said inf ormatioru 

48. The metiiod of daim 39, further comprising routing said information 
—byisaid headed device to said tail-end device over one ofjMd routes other 



30 than said tunnel, if and only if said destination is not serviced by said tail-end 
device. 
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49. An apparati^TO limiting traffic volime in a 

apparatus and a tail-end device, said apparatus having a number of routes to 
said tail-end for routing information to various destinations, the apparatus 
comprising: 

5 turmel establishment logic operably coupled to establish said ttmnel to 

said tail-end device as one of said number of routes; 

receiving logic op»ably coupled to receive information for a 
destination; 

determination logic operably coupled to determine whether said 
10 destination is serviced by said tail-end device; and 

routing logic operably coupled to route said information to said tail- 
end device through said tunnel if and only if said destination is serviced by 
said tail-end device. 

15 50. The apparatus of daim 49, wherein said determination logic is 
operably coupled to determine whether said destination is a directly- 
connected host/ subnet of said tail-end device. 

51. The apparatus of daim 49, wherein said determination logic is 
20 operably coupled to determine whether said destination is within a 

predetermined number of router hops of said tail-end device. 

52. The apparatus of daim 51, further comprising monitoring logic 
operably coupled to monitor tunnel utilizatiori, wherein said determination 

25 logic is operably coupled to dynamically increase said predetermined number 
of router hops if said tunnel is imder-utilized and decrease said 
predetermined number of router hops if said tunnel is over-utilized. 

53. The apparatus of daim 49, wherein said determination logic is ^ 



30 operably coupled to determine whether said destination is said tail-end 
device. 
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54. The apparatu^Rlaim 49, wherein said detennmatio^^ic is 
operably coupled to calculate a shortest path route to said destination, 
determine a shortest path route metric associated with said shortest path 
route, determine a turmd metric associated with said tunnel, and determine 
from said shortest path route metric and said tunnel metric that said tunnel is 
a better route to said destination than said shortest path route. 

55. The apparatus of daim 49, furttier comprising a link state database, 
wherein said determination logic is operably coupled to examine said link 
state database to determine whether said destiMtion is serviced by said tail- 
end device. 

56. The apparatus of daim 49, wherein said timnel comprises a labd 
switdied path to said tail-end device, and wherein said routing logic is 
operably coupled to affix to said information a predetermined label associated 
with said label switched path for label switdung of said information from 
said head-end device to said tail-end device by a number of intermediate 
devices. 

57. The apparatus of daim 49, wherein said routing logic is operably 
coupled to route said information to said tail-end device over one of said 
routes other than said tunnel, if and only if said destination is not serviced by 
said tail-end device. 
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58. A computer program for controlling a head-end devi^Ro limit traffic 
volume in a tuimel between said head-end device and a tail-end device, said 
head-end device having a number of routes to said tail-end for routing 
information to various destinations, the computer program comprising: 

5 timnel establishment logic programmed to establish said timnel to said 

tail-end device as one of said mmiber of routes; 

receiving logic programmed to receive information for a destination; 
determination logic programmed to determine whether said 
destination is serviced by said tail-end device; and 
10 routing logic programmed to route said information to said tail-end 

device through said tunnel if and only if said destination is serviced by said 
tail-end device. 

59. The computer program of claim 58, wherein said determination logic is 
15 programmed to determine whether said destination is a directly-coxmected 

host/ subnet of said tail-end device. 

60. The computer program of claim 58, wherein said determinatioh logic is 
programmed to determine whether said destination is within a 

20 predetermined number of router hops of said tail-end device. 

61. The computer program of claim 60, further comprising monitoring 
logic programmed to monitor tuimel utilization, wherein said determinatioh 
logic is programmed to dynamically increase said predetermined number of 

25 router hops if said tunnel is imder^utilized and decrease said predetermined 
nimiber of router hops if said tunnel is over-utilized. 

62. The computer program of daim 59, wherein said determination logic is 
p rogrammed to determine whether said destination is gaid tail-end device. 



30 



63. The computer program of daim 59, wherein said determination logic is 
programmed to calculate said shortest path route to said destination. 
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determine a shortes^th route metric associate with said s^Kst path route, 
determine a tunnel metric associated wilii said ttinnel, and determine from 
said shortest path route metric and said tunnel metric tiiat said tunnel is a 
better route to said destination than said shortest path route. 

64. The computer program of daim 59, wherein said determination logic is 
programmed to examine a link state database to determine whether said 
destination is serviced by said tail-end device. 



10 65. The computer program of claim 59, wherein said tunnel comprises a 
label switched path from said head-end device to said tail-end device, and 
wherein said routing logic is programmed to affix to said information a 
predetermined label associated with said label switched path for label 
switching of said information from said head-end device to said tail-end 

15 device by a number of intermediate devices. 

66. The computer program of daim 59, wherein said routing logic is 
programmed to route said information to said tail-end device over one of said 
routes other ttian said tunnel, if and only if said destination is not serviced by 

20 said tail-end device. 

67. The OTirqjuter program of daim 59 embodied in a computer readable 
medium. 

25 68. The computer program of daim 59 embodied as a data signal. 
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69. A communi^raon system comprising a head-end de^^ in 
commimication with a tail-end device via a number of routes including a 
tunnel for routing information to various destinations, wherein said head-end 
device is operably coupled to determine a mamber of said destinations that 

5 are serviced by said tail-end device and route information to said serviced 
destinations over said tunnel. 

70. The communication system of daim 69, wherein said serviced 
destinations comprise directly-connected hosts/subnets of said tail-end 

10 device. 

71. The commimication system of daim 69, wherein said serviced 
destinations comprise destinations within a predetermined number of router 
hops of said tail-end device. 

15 

72. The communication system of daim 69, wherein said serviced 
destinations comprise said tail-end device. 

73. The communication system of daim 69, wherein said serviced 

20 destinations comprise a destination for which said timnel is a better route to 
said destination than a predetermined shortest path route to said destination. 

74. The commimication system of daim 69, wherein said tunnel comprises 
a label switdied path from said head-end device to said tail-end device. 



25 



75. The communication system of daim 74, wherein said head-end device 
is operably coupled to affix to said information a predetenxuned label 
assodated with said label switched path for label switching of said 
information from said head-end device to said tail-end device by a ntimber of 



30 intermediate devices, and wherein said tail-end device is operably coupled to 
remove said label from said information and forward said information to said 
destinations based upon destination address information in said information. 
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76. The communication system of daim 69, wherein said head-end device 
is operably coupled to route information destined for other than said serviced 
destinations over one of said number of routes odier than said tunnel. 
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